Subject: Curcuit Flow Control

From: Robin Layland <[email-masked]>
Date: Sat, 16 Oct 93 01:14 GMT

Since there has been very little on the subject of Curcuit flow control I though
I would get it started. 
 
I feel that we have to go with a fixed window algorithm as a based with vendors
having the option to improve on it by using thier codes in the capibilites
exchange. I am against using the Enter Busy and Exit Busy because there is a
chance that the Enter Busy can be lost. I would rather error on the side of
closing down a session that is backed up than allowing it to continue sending.
Neither condition is good but we have to choose which error condition we want to
have.
 
Here is how I see the issue:
 
enter busy     - less overhead but
                          - if the message is lost then the sender keeps sending
until the receiver                               is overrun
fixed window size - more overhead but
                         - if the message is lost then the sender has to stop
 
So which is it : less overhead or more protection????????
 
Comments?

On the procedure matter I was wondering how we decide this issues since the
group was divided?
 
Robin Layland

---

From: "Jim (J.) Cobban" <[email-masked]>
Date: Mon, 18 Oct 1993 11:59:00 +0000

The only good reasons that I can see for considering Enter/Exit_Busy are:

  - simplicity
  - the 6611 acts on these signals if it receives them, although it never
    sends them.

Enter/Exit_Busy are not documented in RFC 1434 and I would prefer that they
not be added to the specification at all, and certainly not as a base
capability.  However I was not present at the flow-control SIGlet meeting
due to other conflicts, so I did not hear all of the arguments in favor.
Contrary to a previous note, I do not believe that there is a possibility
that the signals could be lost, since TCP should guarantee delivery
eventually.  There is a concern that precisely in the situations in which
the signal is most important, it is most likely to be delayed by congestion.
I do not favor requiring the implementation of features which would not
achieve the objective.

Many successful networks use fixed window pacing.  In subarea SNA the
individual sessions use fixed pacing while the virtual routes use variable
windows.  Since there are typically only a small number of virtual routes
between end-points, they would strike me as being more analagous to the
TCP transport connections of DLSw than to to the individual connections
which we are concerned about here.  Fixed window pacing is quite effective
at avoiding end-point congestion.  The principal disadvantage of fixed
window pacing is administrative:  the windows must be manually set, cannot
adjust for changing network conditions, and therefore must be conservatively
chosen resulting in sub-optimal network usage.  However fixed-window pacing
is not difficult to implement.

Adaptive pacing is a significant effort, however I would suspect that most
vendors have had to write the code as part of their APPN support.  There
is a political issue here in that IBM holds a patent on this algorithm.
However there must be other RFCs which contain material which is the subject
of patents, so there must be experience in handling this concern.  I
certainly believe that IBM is more concerned about the success of DLSw than
about pursuing their intellectual property rights in this one area.

The current 6611 does not implement any connection level flow control, and
it is arguably a successful product despite that.  I am therefore not
convinced that there is a requirement to include a flow control mechanism in
the base capability set for DLSw.  If it is the consensus of the SIG that
some flow control mechanism must be included in the base, then I would
prefer that it be a mechanism which is guaranteed to work and yet is simple
enough that the effort would not be an inhibitor to market entry.

---

From: Robin Layland <[email-masked]>
Date: Tue, 19 Oct 93 21:37 GMT

Jim wrote..
 
> I do not believe that there is a possibility

You are right, lost is the wrong word. delayed or even significant delay is a
better way of looking at it. If the message is lost TCP/IP should correct the
problem but this could add significant delay, this is more than likely going to
happen when there is congestion, resulting in the situation only getting worst.

>about pursuing their intellectual property rights in this one area.
 
I think adaptive pacing is best but is to much to ask to be put in the base. As
for vendors already doing it, that is not always the case. Many vendors are
getting their APPN code from others (such as Data Connection). They may write
their own DLSw code. Lets start simple and work up. If we implemented adaptive
rate based flow control we would not need flow control at the TCP/IP (connection
) level.

>enough that the effort would not be an inhibitor to market entry.
 
While the 6611 is out and working I am not sure the 6611 has been scaled up to
the size where flow control makes a difference. Also remember that the curcuit
flow control is aimed at ill-behaved session not effecting well-behaved session.

I think I heard Jim say he favors 1) no pacing and 2) fixed paced. Since the
group decided we should do some type of curciut level pacing in the standards is
this a vote for fixed pacing? (Jim). I favor fixed pacing over Enter busy/Exit
busy because the time we need flow control could be the very time Enter Busy has
trouble reaching the sender. Also, fixed pacing also reflects how the
intermediate nodes are handling traffic to some degree ( I admit it is a poor
indicator and if the queues are backed up only in one direction then it doesn't
reflect the turn condition but its better than nothing. Of course the same logic
applies the the connection level).